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METHOD AUD COMPUTBR SYSTEM FOR HAlilDLZNO XNCREHEHTAIi 
XiMA ZH CZiXENT-BBRVBR COHHDHZCA,TZON 

Field o£ the Invention 

5 The present invention generally relates to electronic 
data processing, and more particularly, relates to 
methods, coi^puter program products and systems for 
client -server communication. 

Background of the Invention 

10 Some software applications can be accessed by a user 
using a conventional Web browser, such as the Microsoft 
Internet Eaqplorer. Typically, such applications provide 
a plurality of pages. A page includes relevant 
information for a graphical user interface * (GUI) 

15 through which the user can interact with the 
application. The page can include multiple components. 
The page is typically generated on a server and then 
transmitted to a client. At the client, the page is 
visualized for a user by the browser. When the user 

20 interacts with the client via the GDI to refresh the 
page, the whole process is repeated. The generally- 
accepted programming design pattern for the above 
described procedure is the so called MVC (Mbdel-View- 
Controller) design pattern. The model, which 

25 encapsulates application data for viewing and 
manipulating, is manipulated by bhe controller and is 
rendered into the view. The view corresponds to a page 
that includes browser-ccmpatibie content. There csm be 
multiple views and controllers for each model. For 

30 exanqple, one view can be used to visualize data of the 
model as a table, while another view can be used to 
visualize the same data as a pie chart. All this is 
done on the server and the complete view is then sent 
to the client. Therefore, the MVC design pattern 
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requires multiple CPU cycles and a high bandwidth of 
the computer network that enables communication between 
the client and the server because the whole page 
(layout information and data) is regenerated on the 
5 server and the resulting View is retransmitted from the 
server to the client over the network. Further, the 
user is confronted with undesired effects, such as 
waiting time and screen flicker, \intil the refreshed 
page is finally presented on the client. 

10 Some conventional browsers, such as the Microsoft 

Internet Explorer IE 6.0, include a feature for 
flicker- free rendering. When the client receives a 
modified page, the browser identifies modified 
components of the page and only replaces these 

15 components instead of the whole page, for exanqple, by 
dynamic HTML injection into the page's document object 
model (DOM) . This leads to a reduction of screen- 
flicker for the user but still consumes CPU time (CPU 
cycles) for page generation and further requires 

20 bandwidth for transmission of the whole page from the 
server to the client » Further, each user interaction 
with the client reqcuires a server round trip and, 
therefore, causes high server load due to page 
generation and transmission. 

25 There is an ongoing need to reduce CPU time 

consuxiiption and bandwidth requirements in client-server 
communication and to reduce undesired effects for the 
user at the same time. 

Sununary of the Invention 

30 Therefore, it is an objective of the present invention 
to provide methods, computer program products and 
computer systems to reduce bandwidth requirements in 
client -server communication when refreshing pagres. 
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To meet this objective, in one embodlmezit of tlie 
present invention a computer system for handllnsr 
incremental data according to claim 1 provides the 
following features: 
5 a) a server-controller on a server receives a 

modification-^ request of a client and, in response to 
the modification- request, modifies an original model of 
an application component that is stored on the server 
into a modified model of the application component; 

IC) b) a server-'renderer generates at least one 

browser- increment that corresponds to the difference 
between the original model and the modified model; 

c) a client -^assembler receives the at least one 
browser-increment from the server and updates an 

IS original DOH component at the client with the at least 
one browser- increment. The original DOM component 
corresponds to the original model and the update 
results in a modified DOM coi^ponent that corresponds to 
the modified model; 

20 d) the modification-request is generated by a 

client - controller . 

Further embodiments of the invention are a server 
according to claim 10. a client according to claim 11, 
a server-side method according to claim 15, a client- 

25 side method according to claim 16, a server-side 
computer program product according to claim 20 and a 
client- side computer program product according to claim 
21. 

When compared to the prior art MVC-pattem, where 
30 model « view and controller are stored and processed by 
the server, the present Invention uses a pattern where 
the view and the controller are split into server-side 
and client-side portions. The server-side portion of 
the view is the server-renderer. The client-side 
35 portion of the view is the client-assembler. The 
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server- side portion of the controller is the server- 
controller and the client-side portion of the 
controller is the client -controller. 

Xt is an effect of the present invention that: the 
required bandwidth for network communication is lower 
when compared to prior art systems where the whole page 
is exchanged between the server and client Instead o^f a 
browser- increment . Often only a minor portion of the 
page is modified. In this case the browser- increment 
transmission requires significant less bandwidth than 
the whole page transmission. 

It is a further effect of the present invention 
that a user who interacts with the client experiences 
an eye pleasing effect because the update of a browser 
component's DOM component with a browser -increment 
results in a flicker-free change of the graphical user 
interface . 

It is a further effect of the present invention 
that the server does not need to hold the state of an 
application because the server receives the state 
Information it needs from the client. 

The aspects of the invention will be realized and 
attained by means of the elements and combinacions 
particularly pointed out in the appended claims. Also, 
the described combination of the feaHures of the 
invent:lan is not: be understood as a limitatrion, and all 
the features cein be combined in other constellations 
without departing from the spirit of the invention, it 
is to be understood that both, the foregoing general 
description and the following detailed description are 
exemplary and esqplanatory only and are not restrictive 
of the invention as described. 
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Brief Deaei- iption of the DrawiiK^ s 

FIG. 1 illustrates a simplified block diagram of an 
eaceraplary computer eysteni that implements 
embodiments of the present invention; 
5 PIGS. 2A to 2D illustrate an inipleinentation of a 
giraphical user interface according to one 
embodiment of the present invention; 
FIG. 3 illustrates interaction of a client with a 

server when operated according to one embodiment 
of the invention; 
PIGS. 4A, 4B illustirate details of client-side handling 
of a browser-increment in one embodiment of the 
invention; 

FIG. 5 illustrates two conq?lemcntary computer program 
products and their main functional blocks that 
may be used in one embodiment of the present 
invention; 

> 

FIG. 6 illustrates a simplified flowchart of a server- 
side method for handling incremental data 
according to the invention; and 
PIGS. 7A, 7B illustrate a simplified flowchart of a 

client-side method for handling incremental data 
according to the invention. 

Detailed De8ciri .ption of che Invention 

Wherever possible, the same reference numbers will be 
used throughout the drawings to refer to the same or 
like parts. 
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Definitions of terms, as used herein after; 

30 

Client: 

A client is a computer device configured to access a 
service that, for example, is provided toy a softwaxre 
application. Typically, clients for accessing Web 
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applications run Web browsers such as Netscape 
Navigator running on a PC Pocket Internet Explorer 
running on a PDA, or a WAP browser running on a cell 
phon'e. 

5 

Server: 

A server is a computer device that is running the 
. application which is accessed by the client. 

10 Page: 

A page includes content (layout' and data) that defines- 
a graphical user interface of a Web application (see 
definition below) . A page typically is rendered on the 
server into a browser compatible format, such as HTML 
IS or HMLi. 

Component : 

A component is a ' basic building block of a page. The 
component always exists within a page. A coK^onent can 
20 include further components. In this case, the component 
is referred to as '•parent-con5>onent« and the further 
components are referred to as » child- components " . A 
component of a page that has no parent- conqponent within 
the page is referred to as root componont. According to 
25 the invention a component has a server-side portion 
that is also referred to as "application component". 
The application component exists during the generation 
of a component descriptor and a browser-increment. This 
allows one to have a stateless server because the 
30 application component can exist for a limited time 
interval only and receive necessary state information 
from a client. The component also has a client-side 
portion that will be referred to. as a browser 
component. The browser component holds the state of the 
3S corresponding component. 
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Con^onent descriptor: 

nhen a page is rendered Into a browser-compatible 
format, each application component oC the page Is 
5 rendered into the browser- coinpatible format. A rendered 
application cwnponent is referred to as ''component 
descriptor . A component descriptor can be implemented 
as name-value pair. 

10 Web Application: 

A Web application, as used hereinafter, includes a set 
of pages. One specific feature of a Web application is 
that it keeps no state at the server. In other words « 
for each request the server receives it creates a state 

15 Of the accessed web application from scratch. After the 
Web application has generated an output, usually the 
stat;e is discarded. 

Dodunent object model: 
20 According to the corresponding W3C definition, the 
Document Object Model (DOM) of a page provides a 
mechanism zo access and manipulate parsed HTML and XML 
content * 

25 Class name: 

A class name of a component specifies the name of a 
server-side component class (e.g., Java class, Java 
Server Pages class, servlet class, Pascal class, C 
cla.ss, C-h+ class, or Business server Pages class) that 

30 implements the application component of the component. 
The application component is an Instance of the 
componenH class that can include a corresponding model, 
server-controller and server-renderer. 

35 
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Script class name: 
The script class name, of a component specifies the name 
of a client - side conqponent script class (e.g., 
S JavaScript class. Java Applets class, or VisualBasic 
Script class) that implements a browser component that 
corre^pnds to an application component. The component 
script class and the component class can have identical 
hierarchies. The browser component is ah instance of 
10 the , cc»iiponent script class . and can include a 
corresponding client- controller, cl lent • assembler and 
DOM component of the current page, a dOM component can 
include one ore more DOM nodes that are used by the 
browser visualize the corresponding component. 

15 

Pxa. 1 is a simplified block diagram of an exemplary 
computer system that implements embodiments of the 
present invention. Computer system 999 includes 
computer 900 and has a plurality of further conqputers 

20 901, 902 (or 90q, with q=O...Q-l, Q any number) . 

Computer 900 can communicate with further computers 
901, 902 over, computer network 990. Computer 900 has 
processor 910, memory 920, bus 930, and, optionally, 
input device 940 and out;put device 950 (I/O devices, 

25 user interface 960) . As illustrated, the invention is 
implement:ad by computer program product 100 (CPP) , 
program carrier 970 or program signal 980. 

In respect to computer 900, computer 901/902 is 
sometimes referred' to as "remote computer", coxiiputer 

30 901/902 is, for s>cample, a server, a peer device or 
other common network node, and typically has many or 
all of the elements described relative to computer 900- 

Conputer 900 is, for example, a conventional 
personal computer (PC), a desktop or hand-held device, 

35 a multlprocessoz: computer, a pen computer, a 
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microproceBSor-based or progranimable consumer 
elect:ronics device, a miniconiputer, a mainframe 
computer, a personal mobile computing device, a mobile 
phone, a portable or stationary personal computer, a 
5 palmtop computer or the like. 

Processor 910 is, for example, a central processing 
unit (CPU) , a micro- controller unit (MOT) , a digital 
signal processor (DSP) , or the like. 

Memory 920 symbolizes elements that temporarily or 

10 permanently store data and instructions. Although 
memory 920 is illustrated as part o£ -coniputer 900, 
memory function can also be implemented in network 990, 
in computers 901/902 and in processor 910 itself (e.g., 
cache, register), or elsewhere. Memory 920 can be a 

15 read only memory (ROM) , a random access memory (HAM) , 
or a memory with other access options. Memory 920 is 
physically in^lemented by computer- readable media, such 
as, magnetic storage media, optical storage media, 
semiconductor storage media or by any other computer 

20 readable storage media. 

Memory 920 can store support modules such as, e.g., 
a basic input output system (BIOS) , an operating system 
(OS) , a program library, a compiler, an interpreter, or 
a text processing tool. 

25 CPP 100 Implements program instructions and 

optionally - data that cause processor 910 to execute 
method steps of the present invention. Xn other words, 
CPP 100 cem control the operation of computer 900 so 
that it operates in accordance with the Invention. For 

30 example and without the intention to be limiting, CPP 
.100 can be available as source code in any programming 
language, and as object code ("binary code**) in a 
compiled form. 
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Although CPP 100 is Illustrated as being stored in 
memozy 920, CPP lOO can be located elsewhere. CPP lOO 
can also be embodied in caririer 970. 

Carrier 970 is illustrated outside computer 900. 
5 For communicating CPP 100 to computer 900, carrier 970 
is conveniently inserted into input device 940. 
carrier 970 is implemented as any computer readable 
medium, such as a medium largely explained above (c£. 
memory 920) - Generally, carrier 970 is an article of 
10 manufacture einbodying a computer readable medium having 
computer readable . program code that can be used to 
cause a computer to perform methods of the present 
invention. Further, program signal 980 can also enibody 
CPP 100. 

15 • Xnput device 940 provides data and instructions for 

processing by computer 900. Device 940 can be, for 
example, a keyboard, a pointing device (e.g., mouse, 
trackball, cx^xaor direction keys) , microphone, 
joystick, game pad, scanner or disk drive. Although the 

20 examples are devices with human interaction, device 940 
can also opetrate without human interaction, snch as, a 
wireless receiver (e.g., with satellite dish or 
terrestrial antenna), a sensor (e.g., a thermometer), a 
• counter (e.g., goods counter in a factory). input 

25 device 940 can serve to read carrier 970. 

Output device 950 presents instructions and data 
that have been processed. For example, this can be a 
monitor or a display, e.g., a cathode ray tube (CRT) 
or flat panel display or liquid crystal display (LCD) , 

30 a speaker, printer, plotter or vibration alert device. 
Similar as above, output device 950 can commtmicate 
with the user, but it can also communicate with further 
computers . 
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Ijoput device 940 axid output device 950 can be 
OQDibined to a single device. Any device 940 saiA 950 can 
be optionally provided. 

Bus 930 and network 990 provide logical and 
physical connections by ccmveying instruction and data 
signals. While connections inside computer 900 are 
conveniently referred to as "bus 930 connections 
between conputers 900-902 are referred to as "network 
990". Optionally, network 990 includes gateways which 
are computers that specialise in data transmission and 
protocol conversion. 

Devices 940 and 950 are coupled to computer 900 by 
bus '930 (as illustrated) or by network 990 (optional) . 

Networks (as network 990) are commonplace in 
offices, enterprise-wide conq^uter networks, intranets 
and the internet. Network 990 can be a wired or a 
wireless network. Exanqples of network implementations 
can be local eirea networks (IiAN) , wide area networks 
(WAN) , public switched telephone networks (PSTN) and 
Integrated Services Digital Networks (ISDN) . Other 
exan^les of network inrplementations are known in the 
art. 

A variety of transmission protocols and data 
formats are known, for exainple, transmission control 
protocol/internet protocol (TCP/IP) , hypertext transfer 
protocol (HTTP) , secure HTTP (HTTPS) or wireless 
application protocol (wap) . 

Interfaces coupled between the elements are also 
well known in the art. For simplicity, interfaces are 
not illustrated. An interface can be, for example, a 
serial port interface, a parallel port interface, a 
game port, a universal serial bus (usb) interface, an 
internal or external modem,, a video adapter, or a sound 
card. 
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Computer and program are closely related. As used 
hereinafter, phrases such as "the computer provides" 
and "the program provides" are convenient abbreviation 
to express actions by a computer that is controlled by 
a px-ogram* 

PIGS- 2A to 2D illustrate an implementation of a 
graphical user interface 955 according to one 
embodiment of the present invention at four consecutive 
time points Tl, T2, T3 and T4. 

The following example of a user's interaction 
with graphical user interface 9S5 is used throughout 
the description to further explain thp present 
invention. However, amy graphical user interface can be 
implemented according to the present invention. For 
example, GUI 955 is presented to the user on output 
device 950 (cf- PIG. 1) of client conqputer 900 (cf. 
FIG. 1) and the user interacts with GUI 955 using input 
device 940. 

QUX 955 is a graphical user interface that allows 
the user to interact with hierarchical data that are 



visual.ized by nodes of tree 955-1. For example, the 
hierarchical data is stored on server computer 901 (cf . 
FIG. 1) . However, the data can be stored on any storage 
device of computer system 999 (cf . FIG. 1) • The user 
can also reset tree 955-1 by using RESET (button) 
9S5-2, The state of . each node of tree 955-1 is 
indicated by a minus sign (-) or a plus sign (+} . The 
minus sign indicates that the status of a node is 
es^anded. The plus sign indicates that the status of a 
node is collapsed. For example, by clicking on a node, 
the user can change the status of the node from 
collapsed (4-) to expanded (-) or vice versa. 
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In PIG. 2A, at Tl, the user gets prompted witli 
tree 955-1, wbereln the states of the various nodes 
are: 

root -node RlJ expanded (-) ; child nodes PLl, FL2; 
'first level node FXtli expanded (-) ; child nodes: 
SLl, SL2; 

first level node FI*2: collapsed} and 

second level nodes SLl, SL2: collapsed (•••) . 

For example, the user selects second level node 
SL2 for e3<panding (e.g., toy clicking on the node). 
After having received the selection of the user, tree 
955-1 is changed accordingly. 

In FIG. 2B, at: T2, the status of second level node 
SL2 has changed to: eaqpanded (-} ; child node Tl.1. Third 
layer node TLl is added to tree 955-1 as a child-node 
of second layer node SIi2. Then, for exainple, the user 
again selectis second level node SIi2 for collapsing 
(e.g., hy clicking on the node). After having received 
the ' selecticm of the user, client 900 changes tree 
955-1 accordingly. 

In FIG. 2C, at T3, the status of second level xuade 
-SL2 has changed back to: collapsed (••■). Third layer 
node Till is hidden in tree 955-1 and not visible as a 
chlld-node of second layer node sii2. For eKample, the 
user then clicks on RBSBT button 955-2 to reset tree 
955-1 to its initial state. TVfter having received the 
RESET request, client 900 changes tree 955-1, 
accordingly . 

FIG. 2D, at T4, shows an exanqple of the initial 
state of tree 955-1. Root-node Rl has status collapsed 
(•!•} and none of its child nodes is visualised. An 
alteimative initial state of tree 9SS-1 is: root -node 
Rl ea^anded (-) ; child nodes: FItl, Fli2 collapsed (■»•). 
Another alternative initial state is: all nodes 
expanded (•«•} . In t:he following description, embodiments 
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of the invention are disclosed to implement a GUI 
behaviour aa described under FIGS. 2A to 2D with low 
network bandwidth requirements and reduced screen- 
flicker for the user when the appearance of GUI 9S5 
5 changes at, before or after the time points Tl to T4. 

PIG. 3 illustrates interaction of client 900 with 
server 901 wh«i qperated according to one embodiment of 
the present invention. As described in PIG. l client 
10 900 communicates with server 901 over network 990. 

Server 901 includes an application con^nent that 
has server-controller 101-1, server-renderer- ioi-2. in, 
the example, an instance of the application component 
further includes original model 200-Tl, For example, 
server- COTt roller lOl-i and server-renderer 101-2 are 
portions of CPP loi (cf. PIG. i) that is stored in 
memory 921 of server 901. Server- controller ' 101-1 
receives 410 a modification- request of client 900. upon 
ireeeiving the modification-request, server-controller 
101-1 modifies 10 originaQ model 200-Tl into modified 
model 200 -T2. In case of multiple application 
components, corresponding server- controllers let the 
application components influence each other, in other 
words, for exeunple, server- controller loi-i can raise 
25 an event that makes a further server- controller modify 
a farther model. 

Original model 200-Tl and modified model 200-T2 of 
the application component are illustrated by the same 
circle symbol. Referring back to the example of PIG. 
2A, original model 200-Tl is visualized as tree 955-1 
at Tl. The modification- request corresponds to the 
user's interaction to es^and second level node Sli2. 
Modified model 200-T2 is visualized as tree 955-1 at 
T2. 
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One emboddLment of the Invention uses an object- 
oriented coniponent architecture framework (also 
referred to as framework hereinafter) with inheritance. 
The framework has a server-side portion and a client- 
side portion. The framework can be implemented as a 
function pool, such" as a set of methods of one or more 
classes. For example, components implement standard 
graphical user interface elements such as buttons 
(e.g., RBSBT 955-2), trees (e.g., tree 955-1), tables. 



tab strips or any other interface element in a 
graphical user interface, such as GUI 955. Further, a 
component can have properties and of£ers services, such 
as graphical user interface creation from a graphical 
user interface deacription file, drag and drop 
interaction handling, and component administration. The 
framework supports component creation and deletion at 
runtime, as well as access to all properties of a 
component at runtime. Additionally, the framework can 
provide general services, such as a broadcasting event 
mechanismj modification of the graphical user 
interface, and server access without page replacement. 

A component can be installed without a special 
registration procedure similar to a procedures used by 
servlet engines, such as Tomcat. In other words, 
installing a component automatically makes the 
conqponent available to the framework. 

For exanqple, an application component of a 
component is defined by a component class, such as a 
Java class, a Java Server Pages class, a servlet class, 
a Pascal class, a C class, a C-h-h class or a Business 
Server Pages class. The component class runs on server 
901. For example, the coiqponent class implements the 
model (e.g., model 200-Tl) as well as the server- 
renderer (e.g., server-renderer 101-2) and the ©erver- 
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controller (e.g., server- controller 101-1) of the 
component • 

For visualizing original model 200 -Tl server- 
renderer 101-2 generates browser-conipatible code, such 
5 as HTML, XHIML or MML. Initially, server- renderer lOX-2 
generates a component descriptor from original model 
200-T1 and sends the component -descriptor to client 
900. The component descriptor corresponds to a browser- 
compatible description of tree 955«-X in the example of 

10 FIG* 2A (at Tl) • Those skilled in the art know how to 

I 

generate the conipc»ient descriptor i for example on the 
base of a Java page, a iTava Server Page or alternative 
server-side descriptions of original model 200-Tl. For 
example, a coznponent script class, such as a JavaScript 
15 class, a JavaApplets class or a VisualBasic Script 
class, generates original browser component 300-Tl 
baeed on the corresponding component descriptor of 
original model 200-Tl. 

In one embodiment, con^onencs include properties 
20 as a set of name ^value-pairs, wherein the properties 
are part of a corresponding component descriptor. 
Standard properties of a component are: an identifier, 
a class name, a script class name and. a parent 
coRiponent name. The identifier is unique on a page that 
' 25 includes the component. The class name and the script 
class name specify the names of the component class and 
the component script class of the component. The parent 
component name is the identifier of the parent 
component of the component. For example, the script 
30 class name can be derived from the class name. The 
script class can be used to create a browser component 
that corresponds to the application con^onent of the 
component • 

When a page is initially generated on server 901, 
35. the component class of each application coiqponent of 
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the page Is called with the correaponding properties of 
the application component. The properties include all 
information about the application component that is 
knovm on server 901. The component class writes a 
component-descriptor of the application component to 
the page by using, for example, one or several 
functions of the interface of the component class. 
Bxeunples of these functions ares 



In the example, all three functions have a set of 
parameters. For exainple, a parameter "properties" is a 
set ' of name-value pairs describing the application 
component. A further parameter "output" is used to 
write data into the page, wherein the data is sent to 
the client in an output stream. Writing data to a page 
that is sent to the client in an output stream will 
also be referred to as writing or rendering data to the 
out:put stream. 

Ftinction prolog {,„) writes a component descriptor 
header to the output stream. The component descriptor 
header is a browser compatible description of name- 
value pairs describing the application component. 

Fxmction base (...) renders base content of the 
component: to the output stream. The base content is 
defined as the initial content of a component that is 
presented to the user. The framework is able to combine 
the base contents of multiple components within a page. 
This results in a description of GUI 955- For example, 
the base content of a component includes further name- 
value pairs, such as a content name-value pair that is 
a browser compatible description of the initial content 
of tlie Goxnponen^ or a. reference to the inicial concent 
thali is presented to the user. A type specification 



• prolog (.„) 

• base (...) 

• epilog 
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name -value pair can describe a reference type to the 
Inlcxal content- For example, if the type specification 
name- value pair includes "HTML", then the corresponding 
cont:ent name-value pair contains the initial content as 
an HTML string ♦ Examples for other reference types are 
«»DOM", "WML" and "link" {link to another page). 

In case the type specification name-value pair 
includes reference type **DOM", the content name-value 
pair includes a unique identifier of a corresponding 
DOM node of the page. For example , at page generation 
time, server 901 can generate HTML code into the page, 
where the HTML code has an ID attribute that includes 
the ' unique identifier of the DOM node as the value of 
the ID attribute. The same applies to other reference 
types. 

Function epilog {_) writes client-side script to 
the output stream to register the component with the 
framework » 

Some functions for writing the component 
descriptor to the output stream can be handled by a 
super -^class of the component class, in other words, a 
super-class can write properties that are the same for 
a plurality of coiiqponents (e.g-, class property) to the 
output stream. The component class, which is a sxib- 
class of the super-class, can add properties of a 
specific component to the corresponding output stream. 

' The following coding block is a simplified HTML 
code example of a component descriptor of a tree 
component ; 

<table ids » node '> 



<tr><td>id</td><:td>node</td></tr> 

<tr><td>parent</td><td>parentContainer</td></tr> 
<tr><td>class</td><td>SPNode</td></tr> 
<tr><:td>positionx</td><td>0</td></tr> 
< t r X t d>poai t ionY< / 1 d>< t d> 0 < / 1 d>< / 1 r > 
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<tr><td>Width</td><td>82</td></tr> 
*itr><td>Height</td><td>2S</t:d></tr> 

<tr><td>CoxitentType< / tdx td>HTMIi</ tdx/ b3r> 
5 <1:r><td>content</td><td><:inML--dtring of node . 

base content></t:d></t:r> 

• V • 

</table> 

<scrlpt lan^uage^^ • JavaScript ' > 
10 SPFrameworfc • registercomponent ( » node » , • SPNode • ) ; 

</scrlpt> . . 

The tables-portion of the coding block Includes the 
component descriptor header (e.g., identifier, parent, 
class, positlonX, positionY, width, Height} generated 
15 by, for example, function prolog () and further includes 
the conqponen t ' s base content (e.g., cont entType # 
content) generated by, for example, fiuiction baseO. 
Referring back to the example of FIO. 2A, the component 
descriptor corresponds to a description of tree 955-1 
20 at Tl, 

The iTavascript portion of the coding block can be 
generated by function epilog (} « 

When client-controller 101-1 modifies 10 original, 
model 200-Tl into modified model 200-T2, server- 

25 renderer 101-2 generates 420 at least browser- increment 
300*x in a browser- compatible format. Depending on the 
modification 10, more than one browser- increment can be 
generated by server- renderer l01-*2. Xn the example, 
browser -Increment 300-1 corresponds to the difference 

30 between original model 200-Tl and modified model 
200-T2- Referring back to the example of PIG, 2B, 
browser- increment 300-1 corresponds to third level node 
TLl. Server 901 then sends 430 at least browser- 
increment 300-1 to client 900. 
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, For example, the interface of the componexit class 
haj5 a further f \uiction increment {„•) • Function increment 
(^) can have parameters "properties" and "output, 
which can be the same as for. the previously explained 
functions of the interface. It can have a further 
parameter "parameters"^ which is a further set of name- 
value pairs similar to parameter "properties"* 
Function increment () can be called when a user 
interaction <e.g,, when the user indicates to expand 
second level node SL2) that affects the model of the 
application component (e.g., original model 200-Tl) 
requires a change in at least one part of the 
corresponding browser component for its visualization. 
Function increment () has the task to generate 420 a 
corr;esponding browser- increment (e.g., browser- 
increment 300-1), and write it to the output stream. 
The name -value pairs provided with parameter 
"parameters specify the exact format of the browser- 
increment to be generated. 

Referring back to the example of FIG. 2B, an HTML 
example of browser- increment 300-Z can include the 
following statement: 

<div id«-/Rl/FLl/SL2/TLl»>node label</div>- 

The identifier •/R1/FI.1/SL2/TL1' describes the 
path of the browser-increment which corresponds to 
third level node TLl at T2 . The node label can be an 
icon (e.g-r in a circle) that visualizes the node 

or a text or any other graphical representation. 

,Xn an alternative embodiment/ a single function 
(e . g . # function all_in_one (...) ) or any other number of 
functions can be used to perform the previously 
described tasks that are needed to write the 
corresponding data to the output stream. 

TO summarize, in one embodiment of the invention, 
the server- side component class has two tasks s 
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a) On request f write a component descriptor to the 
output stream, wherein the coxnponent descriptor lists 
all' component properties. Further, generate the 
component base content and vrr it e it to the output 
stream. Ftirther, write code to the output stream that 
registers the coxi^onent with the framework. 

b) On request, generate a browser •-increment, as 
described by the parameters. Write the browser* 
increment to the output stream. 

Client 900 includes a browser contponent which 
corresponds to the application component and that has 
corresponding client-assembler 100-1 and cllent- 
controller 100-2. For exan^le, client-controller 100-2 
and client -assembler loo-i are portions of CFP 100 (cf . 
FIG. 1) that is stored in memory 920 of client 900. An 
instance of the browser component (e.g., a oravaScript 
object) is instantiated from the corresponding 
contponent script class. For example, the client-side 
portion of the framework uses a constructor that 
receives a pointer to the component descriptor. The 
browser conQ>onent extracts properties and corresponding 
property values from the component descriptor and adds 
them to the insteuice of the browser component . The 
instance of the browser coxnponent includes original dom 
component 300«T1. 

After original model 200-Tl has been modified, 
clients-assembler 100-1 receives 520 browser- increment 
300-1 and updates S3 0 original DOM component 300-Tl 
(that corresponds to original model 200-Tl} with the at 
least browser- increment 300-1. This restxlts in modified 
DOM component 300-T2 that corresponds to modified model 
200-T2. Modified DOM component 300-T2 and origdLnal DOM 
component 300-Tl are illustrated by the same ellipse. 
For exanqple, modified DOM component 300-T2 and original 
DOM component 3 00-Tl are instances (e.g», iTavaScript 
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objects) of the corresponding component script class. 
In one embodiment of the invention, the component 
script class that corresponds to the component class of 
a component is running at client 900 and implements, 
for example, client-assembler 100-1 and client- 
controller 100-2. For example, the Interface of client- 
assembler 100-1 includes function handleResponse . 

In one embodiment of the invention function 
handleResponse 0 is called, when client-assembler 100-1 
receives 520 browser- increment 300-1 from function 
increment of the component class. For example, the 
framework passes parameter "output" of function 
increment () to a parameter "response" of function 
handloResponse ( } . Further parameter "target" of 
function handleResponse ( } is a value that is passed to 
server 901 in the receiving 410 step. When function 
handleResponse ( } is called upon having received 520 
browser- increment 3 00-1, parameter "target" indicates 
to the client the recipient (browser component) of 
browser- increment 300-1. The recipient can be the same 
as the original requestor but can also be different 
from the original requestor • 

' A first example to retrieve browser- increment 
300-1 from server 901 is by using a script tag. A 
second exaniple is by using a hidden HTML iFrame 
element » 

To retrieve a browser -increment by using a script 
tag (e.g., iJavaScript) , the client-side portion of the 
framework performs the following steps. 

First, a corresponding recjuest URL is generated. 
For example, the client- side portion of the framework 
retrieves a server generated basic request URL from the 
page received from the server and appends request 
specific parameters. 
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Then a script tag (e.g., stag) is generated that 
has a SCR attribute. For this, for example, one can use 
a iJavaScript Statement, such as: 

var stag = createKode{ "script") . 

Then the request url is assigned to the SRC 
attribute of the script tag (stag.SRC = request URL) . 

Then the script tag is added to the DOM of the 
page. For example, this can be achieved by using the 
JavaScript statement document. body. appendchild( stag) . 

Once the script tag is added to the dom, the 
client sends the server request to the server. The 
server generates a script statement that includes the 
response to the request. For example, the server can 
create a call to the client -side portion o£ the 
framework, passing the results of the server request as 
a parameter: 

Framework . handleResponse (zresult ) 

The function handleResponse (_) interprets the 
result at the client and passes the result for each 
component to the corresponding components. 

' other scripting languages, such as VBScript, can 
be equally be used to implement browser- incrament 
retrieval using script tags. 

The second example uses iPrames instead of script 
tags for browser- increment retrieval. In this example 
the page received from the server includes a hidden 
IFrams that is generated into the page by the server- 
side portion of Che framework. The client- side portion 
of the framework then generates a corresponding request 
URL as described in the first example. 

Then, the request DHL is assigned to the SRC 
attribute of the hidden IFrame. 

Once the request URL is assigned to Che SRC 
attribute, the client sends the corresponding request: 
to the server. The server can generate a script as 
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description of what actions are required at clje client. 
In the latter case, the client -side framework 
interprets the description and acta accordingly. 

When client-assemibler 100-1 notices that an update 
of the browser conqponent is requested (e.g., through 
user interaction) , client -controller 100-2 generates 
the modification- request that is sent 510 to server 
901. Further functions of client -controller 100-2 are 
e^lained in FIGS. 4B and FIG. 5. 

When sending only browser- increment 300-1 instead 
of the whole modified browser component from server 901 
to client 900, less bandwidth is required for the 
client -server communication over network 990 and less 
CPU time of the server is consumed for generating 
browser-increment 300-z than for regenerating the full 
page . 

When original DOM component 300-Ti is updated with 
browser-increment 300-1 through client -assembler- lOO-i, 
screen- flicker which often occurs when replacing a full 
page, is reduced. 

PIGS. 4A, 4B illustrate further details of client- 
side handling of browser- increment 300-1 in one 
embodiment of the invention. Preferably, upon having 
received 520 browser-increment 300-1, client-controller 
100-2 stores browser- increment 300-1 in cache-memory 
920-c of the client 900. 

PIG. 4A illustrates the deactivation of browser- 
increment 300-1 upon receiving deactivation- request 
DAR. Deactivation- request I3AR can be generated by the 
user interacting with client 900 as described in FIGS. 
2A, 2B or it can be generated by another computer in 
computer system 999. For exEunple, deactivation- request 
tJAR is received by client -controller 100-2. Then, 
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client-controller lGO-2 instructs 610 ci ient-aBeerablear 
100-1 to deactivate 550 browser- increment 300-X in 
modified DOM component 300-T2 resulting in deactivated 
DOM component 300-T3. For example, browser- increment 
5 300-r can be deactivated by setting a corresponding 
deactivation flag. In deactivated DOM component 30O-T3, 
browser- increment 300-1 is suppressed (e*g.^ by 
deletion or setting a deactivation flag; illustrated by 
crossing out) • Modified DOM component 300-T2 and 

10 deactivated DOM component 300-T3 are illustrated by the 
same ellipse. Referring back to the exainple of FX6S. 
2B, 2C, modified DOM component 3 00-T2 corresponds to 
tree 955-1 at T2 where second level node SL2 is 
expanded and third level node Tl,i is included- 

15 Deactivated DOM consonant 3 00-*-T3 corresponds to tree 
955-1 at T3 where third level node TLl is suppressed 
and second level node SIi2 is collapsed, ivl though the 
visualization of tree 955-1 at Tl is identical with its 
visualization at T3, the status of client 900 at Tl is 

20 different from the status at T3 because client- 
increment 300-1 is available in cache 920-C at T3 but 
not 'at Tl. This affects the behaviour of client 900 in 
case of a reactivation-request as explained in 
reference to FIG. 4B. 

25 For example, browser components can interact at 

client 900 without contacting server 901. Referring 
back to the example of FZO. '2D, at T4, the user has 
used RESBT button 955-2 generating a reset-request to 
collapse tree 95S-1 to root --node Rl. Correspondingly, 

30 at client 900, a RESBT browser component (not shown) 
that corresponds to a RESET application component (not 
shown) at server 901, interacts with the browser 
component visualizing tree 955 *-l so that all further 
browser- increments (not shown) of the browser coniponent 

35 are deactivated in the corresponding DOM component 
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(e.g*, deactivated DOM component 300-T3) with the 
exception of a browser- increment that corresponds to 
root -node Rl- 

PIG, 4B illustrates the reactivation of browser- 
5 increment 300-1 upon client-controller 100-2 receiving 
reactivation-- request HAR. Client -controller 100-2 
retrieves browser-increment 300-1 from cache-memory 
920^C and instructs 620 client -assembler 100-1 to 
reactivate browser -increment 300-1 in deactivated DOM 

10 component 3 00-T3. The reactivation results in 
' reactivated DOM component 300-T3', Referring back to 
the example of PIG. 2A, the user interacts with client 
900 in the same way as at Tl- However, instead of 
requesting browser-delta 300-1 from server 901 to 

15 arrive at modified DOM component 300-T2 that 
corresponds to the visualization of tree 955-1 at T2r 
client 900 simply retrieves browser-increment 300-1 
from its own cache 902 -C and reactivates 570 browser- 
increment 300-1 in deactivated DOM component 300-T3- 

20 The resulting reactivated DOM component 300-T3' is 
identical with modified DOM component 300-T2. 

By caching browser- increments at client 900 and 
enabling interaction of browser components at client 
900 1 the load of server 901 is reduced because the 

25 number of requests to the server is reduced, as the 
client 900 can handle specific events on its own 
without contacting server 901. 

PIG. 5 illustrates two complementary computer program 
30 products CPP 101 (server program) , CPP 100 (client 

program) and their main fimctional blocks that may be 

used in one embodiment of the present invention. For 

example, CPP 100 can be a browser. 

The framework is implemented in server- side 
35 portion iOX-10 as a part of CPP 101 and in client-side- 
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portion 100-10 as a part of CPP 100. ns eacplained 
earlier, the framevn^rk provides generic fxinctions that 
can be applied to multiple components. 

DOM 100-9 is used to present the graphical user 
5 interface of an application to the user. In the 
exainple, DOM 100-9 represents a page including tree- 
component 955-1 (cf . PIG. 2A) and reset component 955-2 
(cf - FIG. 2A) . When the user interacts with CPP lOO 
(e.g., by indicating that a specific tree node should 

10 be expanded) so that model 2o'o-Tn (n= 1,2, .-,N) at 
server 901 will be affected, corresponding client 
controller 100>2 gets notified 70i about the user 
interaction sma sends 702 a corresponding request to 
CPP 101 running on server 901. For example, client - 

15 controller 100-2 can subscribe to specific browser 
events and is notified when a coarresponding browser 
event is raised through the user interaction. 

In case the user interaction can be handled by 
client- controller 100-2 without contacting server 9 ox, 

20 client-controller 100-2 can instruct 702" corresponding 
olient-aosembler 100-1 to update 803 DOM 100-9 of the 
page that is currently visualized by the browser for 
adjusting the visualization of DOM 100-9 according to 
the user interaction. 

m case the user interaction requires server 901 
to be involved, CPP 100 sends 702 a corresponding 
request to Cpp loi. The request makes server-controller 
101-1 to modify 703 the corresponding model 20O-xn 
accordingly. Server- renderer 101-2 renders/generates 

30 801 irfodel 200-Tn after having been modified 703. The 
result of the rendering 801 is a description of the 
model that can be used for its visualization. This 
description is then m&at to client 900. 

In one embodiment of the invention, the 

35 description is sent 802 from server-renderer 101-2 to 
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cli.ent-asseirtbler lOO-l. Client-aesembler uses the 
description to update 803 DOM 100-9 accordingly by 
changing a corresponding node of DOM 100-9. 

In another embodiment of the invention the 
5 description can be sent 702 from server-controller 
101-1 to client-controller 100-2, which then instructs 
702' client -assembler 100-1 to update 803 DOM 100-9 
accordingly. 

In a still further embodiment of the invention, 
10 the description is sent from server-side framework 
101-10 to client-side framework lOO-iO, where it is 
dispatched to the corresponding client-controller 
100-2. 



15 FIG, 6 summarizes server- side aspects of the invention 
by a simplified flowchart of server-side method 400 
that can be performed by one embodiment of the 
invention. For example, method 400 for handlixig 
incremental data on server 901 in computer system 999 

20 can be performed by computer program product 101 having 
instructions that, when loaded into memory 921 of 
server 901, cause at least one processor 911 of server 
901 to execute method 400. Method 400 includes the 
steps receiving 410, generating 420 and sending 430. 

25 In the receiving step 410, server- controller 101-1 

receives a modification-request from client -controller 
100-2. client -controller 100-2 is running on client 900 
of con^uter system 999. The modification-request makes 
server 901 modify original model 200-Tl into modified 

30 model 200 -T2, which are both stored, for exanqple, in 
memory 921 of server 901. 

In the generating step 420, server- renderer xoi-2 
generates at least one browser- increment 300-1 that 
corresponds to the difference between original model 
35 200-Tl and modified model 200-T2. 
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In the sending step 430 server 901 sends the at 
least one browser- increment 300-1 to client-assembler 

100- 1 of client 900. client 900 uses browser- increment 
300-1 to update original DOM con^ionent 300-Tl with the 

5 at least one browser- increment 300-1. The update 
results in modified dom component 300-T2 that 
corresponds to modified model 200-T2, whereas original 
DC»I conqponent 300-Tl corresponds to original model 200- 
Tl. 

10 

PIG. 7A summarizes client -side aspects of the invention 
by a simplified flowchart of client -side method soo 
that can be performed by one embodiment of the 
invention. For example, method 500 for handling 
15 incremental data on client soo in computer system 939 
can be performed by conqcniter program product 100 having 
instructions that, when loaded into memory 920 of 
client 900, cause at least one processor 910 of client 

900 to execute method 500. Method 500 includes the 
20 steps sending 310, receiving 520 and updating 530. 

In the sending step .510,. client-controller 100-2 
sends a modification-request to server- controller 

101- 1. Server-controller lOl-l is implemented on server 

901 of cooiputer system 999. 

^5 In the receiving step 520, client-assembler 100- 1 

receives at least one browser- increment 300-1 frcxn 
server 901 as a response to the modification request. 

In the updating step 530, client-assembler 100-1 
updates original DOM component 300-Tl with the at least 

30 one browser-increment SOO-i resulting in a modified DOM 
conrponent 300-T2. Original DOM component 300-Tl 
corresponds to original model 200 -Tl and modified DOM 
component 300-T2 corresponds to modified model 200-T2. 
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PIG. 7B continues the eiinplified flowchart of PIG, 7A. 
The steps illustrated by dashed squares can be 
performed by method 500 in various eiribodiinente of the 
invention. The steps do not necessarily require seeps 
5 510 to 530 to. be performed before, in case of using an 
alternative basis mechanism for handling of incremental 
data, the steps illustrated in FIG. 7B can still be 
used for client-side ervent -handling. 

in a deactivation example, method 500 includes the 
10 further steps storing 540 and deactivating 550. 
. . . ... '. -In -the storing step 540. client 900 stores the at 

least one browser-increment 300-1 in its cache-memory 
920-C, 

In the deactivating step 550, client -controller 
IS 100-2 has received deactivation-request DAR and, as a 
consequence, client-assembler lOO-i deactivates 
browser- increment 300-1 in the corresponding DOM 
component . 

In a reactivation example, of the invention method 
20 500 includes the further steps retrieving 560 and 
reactivating 570. However, it does not require to 
execute the deactivation step 550 before. 

In the retrieving step 560, client 900 retrieves 
the at least one browser- increment 300-1 from cache- 
25 memory 920-c, where it was stored using storing step 
540. Per example, this can be initiated by 
reactivation-request RAR that is received by client- 
controller 100-2. 

Then, in the reactivating step 570, elient- 
30 assembler 100-1 reactivates browser-increment 300-1 in 
the corresponding DOM coiqponent. 



, '.X 4 Alter t R; 9<l 



16:35 




m WflU-DORF 



1227 764433 



2002— 117-BP 



31 



1. A computer system (999) for handling incremental 
data cons>risizig; 

a server-controller (lOi-i) for receiving a 
modification- request from a client (900) to 
modify an original model (200-Tl) of an 
application component that is stored on the 
server (901) into a modified model (200-T2) of 
the application component; 
a server- renderer (101-2) for generating at least 
one browser- increment (300-1) that corresponds 
to the difference between the original model 
(200-Tl) and the modified model (200-T2) ; 
'a client-assembler (lOO-i) receiving the at least 
one browser- increment (300-1) from the server 
(901) and updating at the elient: (900) an 
original DOM component (300-Tl) of a browser 
component with the at lease one browser- 
increment (300-1), resulting in a modified 
document object nndel (DOM) ccxuponent (300-T2) 
that oorre^onds to the modified model 
(200-T2), wherein the original DOM component 
(300-Tl) corresponds to the original model 
(200-Tl); and 

a client-controller (100-2) for generating the 
modification-request . 
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2. The computer system (999) of claim 1, wherein the 
' client -controller (100-2) stores the at least one 

browser- increment (300-1) in a cache-memory (920-C) 
of the client (900) and instructs the client- 
5 assembler (loo-l) to deactivate the at least one 

browser- increment (300-1) upon receiving a 
deactivation-request (DAR) (DAR) . 

3. The computer system (999) of claim 2, wherein the 
10 client -controller (100-2) retrieves the at least 

one browser- increment (300-1) from the cache-memory 
(920-C) and instructs the client -assembler (100-1) 
to reactivate the at least one browser-increment 
(300-1) upon receiving a reactivation-request 
15 (SAR) . 

I 

t 

4. The computer system (999) according to any of the 
claims l to 3, wherein the client -controller 
(100-2) instructs the client -assembler (100-1) to 

20 reset the original or modified DOM component 

(300-Tl, 300-T2) upon receiving a reset -request. 

5. The computer system (999) according to any of the 
claims i to 4, wherein the original model (200-Ti) 

25 and the modified model {200-T2) are defined by a 

component class selected from the group of Java 
class, Java Server Pages class, servlet class, 
Pascal class, C class, C++ class, and Business 
Server Pages class. 

• 30 
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6> The coR^uter system (999) according to any oc the 
claims X CO 5, wherein the browser component is 
, defined by a c^nponent script class selected from 
the group of JavaScript class, JavaApplets class 
5 and VisualBasic Script class. 

7. The computer system (993) of claim 5, wherein the 
ccnnponent class inclement s at least a portion of 
the server-controller (101-1) and the server- 

10 renderer (101-2) . 

8. The coiputer system (999) of claim 6, wherein the 
ccmiponent script class implements at least a 
portion of the client- controller (100-2) and the 

15 client -assembler (100-2) . 

9. The computer system (999) of claim 6, wherein the 
component script class and the component class have 
identical hierarchies. 

20 
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10. A server (900) in a computer system (999) for 
handling IncrementfiLL data comprising: 
a server- controller (101-1) for receiving a 
modification-request from a client -controller 
5 (100-2) of a client (900) in the computer 

system (999) to modify an original model 
(200-Tl) of an application component that is 
stored on the server (901) into a modified 
model (200-T2) of the application component; 
10 and 

a server-renderer (101-2) for generating at least 
one browser- increment (300-1) that corresponds 
to the difference between the original model 
(200-Ti) and the modified model (200-T2) ; the 
15 at least cme browser-increment (300-1) made to 

be sent bo a client -assembler (100-1) of the 
client (900) for updating an original DOM 
conponent (300-Tl) that corresponds to the 
original model (200-Tl} with the at least one 
20 ' browser-increment (300-1) , resulting in a 

modified DOM caa^oneat. (300-T2} that 
corresponds to the modified model (200-T2) . 
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handling Incremental data comprising: 

a client-controller (100-2) sending a modification- 
request to a server-controller (lOl-l) of a 
server (901) in the computer system (999) ; and 

a client -assembler (lOO-i) receiving at least one 
browser- Increment (300-1) £rc»R the server (901) 
and updating an original DOM component (300-Tl) 
that corresponds to an original model (200-Tl) 
of an application component with the at least 
one browser-increment (300-1) , resulting in a 
modified DON component (300-T2) that 
coxrresponds to a nusdifled model (200-T2} of the 
application component, wherein the sezvez*- 
eontroller (lOl-l) modifies the original model 
(200-Tl} being stored on the server (901) into 
the modified model (200-T2) ; and a server-- 
renderer (101-2) of the server (901) generates 
the at least one browser- increment (300-1) that 
corresponds to the difference between the 
original model (200-Ti) and the modified model 
(200-T2) . . 

12. The client (900) of claim 11. wherein the client- 
controller (100-2) stores the at least one browser- 
increment (300-1) in a cache-memory (920-C) of the- 
client (900) and dLnstructs the client-assembler 
(100-1) to deactivate the browser- Increment (300-j) 
iipon receiving a deaotivation-request (BAR) . 
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13. The client (900) of claim 12, wherein the client- 
controller (100-2) retrieves the at least one 



(920-C) and instructs the client -assembler (100-1) 
to reactivate the at least one browser-increment 
(300-1) upon receiving a reactivation-request 



14 /The client (900) according to any of the claims 11 
to 13, wherein the • client-controller (100-2) 
instructs the client -assembler (lOO-l) to reset the 
original DOM component (300-Tl) upon receiving a 
reset ^ request . 



browser-increment (300-1) from the cach^-memoiY 
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. A method (400) for handling incremencal data on a 
server OOl) of a computer system (939) comprising 
, the steps; 

receiving (410) by a server-controller (lOl-i) a 
modification-request from a client -controller 
(100-2) belonging to a client (900) of the 
comiputer system (99$) to modify an original 
model (200 -Tl) of an application component that 
is stored on the server (901) into a modified 
model (200-T2) of the application component; 

generating (420) by a server-renderer (101-2) at 
least one browser- incremezit (300-x) that 
corresponds to the difference between the 
original model {200-Tl) and the modified model 
(200-T2); and 

sending (430) the at least one browser -increment 
, (300-1) to a client-assembler (lOO-l) of the 
client (900) for updating on the client (900) 
an original DOM component (300-Tl) that 
corresponds to the orlgizial model (200-Tl) with 
the at least one browser- increment (300-1) , 
resiilting in a modified DOM component (300-T2) 
that corresponds to the modified model 
(200-T2) . 
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16, A method (500) for handling incremental data on a 
client (900) of a con^uter system (999) comprising 
the steps: 

sending (5lo) from a client- controller (100-2) a 
5 modification-request to a server- controller 

(101-1) of a server (901) of the computer 
system (999) ; and 
receiving (520) by a client-assembler (100-1) at 
least one browser -increment (300-1) from the 
10 server (901) as a response to the modification 

request; and 

.updating (530) an original DOM component (300-Tl) 
that corresponds to an original model (200-Tl) 
of an application component with the at least 

15 one browser- increment (300-1) , resulting in a 

modified DOM coniponent (300-T2) that 
corresponds to a modified model {200-T2) of the 
application component, wherein the server- 
controller (101-1) modifies the original model 

20 (200-Tl) being stored on the server (901) into 

the modified model (200-T2) ; and a server- 
renderer (101-2) of the server (901) generates 
the at least one browser- increment (300-X) that 
corresponds to the difference between the 

25 original model (200-Tl) and the modified model 

(200-T2) . 

17. The method (500) of claim 16^ comprising the 
further step; 

30 storing (540) the at least one browser- increment 

(300-1) in a cache-memory (920-C) of the client 
(900) . 

18 • The method (SOO) of claim 17, comprising the 
35 further step: 
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deactivating (550) the browser- increment (300-1) by 
the client -assembler (lOO-i) upon the client- 
controller (100-2) having received a 
deactivation-reguest (DAR) . 



19. The method (500) of claim is, comprising the 
further steps: 

retrieving (560) the at least one browser- increment 
(300-Z) from the cache-memory O20-C) ; amd 

reactivating (570) the browser- increment (300-1) by 
the client-assembler (loo-i) upon the client- 
controller (100-2) having received a 
reactivation-request (RAR) . 

20. A computer program product (101) comprising 
instructions that, when loaded into a memory (921) 
of a server (901) , cause at least one processor 
(911) of the server (901) to execute the steps of 
claim 15. 

21. A computer program product (100) comprising 
Instructions that, when loaded into a memory (920) 
of a client (900) , cause at least one processor 
(910) of the server (900) to execute the steps of 
any of the claims 16 to 19, 
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22. A eoinputer system (999) for handling incremental 
data comprising: 

a client-controller (100-2) generating a 
modification-request; 
5 a server- controller (lOl-l) modifying (703) a model 

(200-Tn) of an application component on • a 
server (901) as a response to the modification- 
request ; 

a server -renderer (101-2) generating (801) at least 
10 one browser- increment (300-1) after the model 

• ■ (200-Tn) has been modified (703); and 
a client -assembler (100-1) receiving the at least 
one browser- increment (300-1) from the server 
(9 ox) and updating an instance of a browser 
15 component at the client (9O0) with the at least 

one browser-increment (300-1) , wherein the 
browser component corresponds to the 
application component. 

20 
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UBTBOD JOiD COMPUTER SYSTEM FOR BAnDLZMO INCRBSIEllTAIi 
DATA XN CLXBHT-SBRVER COHUOHZCATZON 

i^batract o£ the Inventicm 

. 5 

A server- controller (lOi-i) on a server (901) receives 
(410) a modification-request generated by a client- 
controller (100-2) of a client (900) to modify an 

original model (200-Tl) of an application component 
10 that is stored on the server (901) into a modified 

model (200-T2) . A aexver-renderer (101-2) generates 
(420) at least one browser-increment (300-1) that 

corresponds to the difference between the original 

model (200-Tl) and the modified model (200-T2) . a 
15 client-assembler (lOO-i) receives the at least one 

browser-increment (300-1) from the server (901) and 

updates at the client (900) an original DOM component 
(300-Tl) tliat corresponds to the original model 
(20G-T1) with the at least one browser-increment 
20 (300-1), resulting in a modified DOM component (300-T2) 

that corresponds to the modified model (200-T2) . 
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